* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download Dias nummer 1 - Webstorage
Operational transformation wikipedia , lookup
Business intelligence wikipedia , lookup
Data vault modeling wikipedia , lookup
Concurrency control wikipedia , lookup
Entity–attribute–value model wikipedia , lookup
Clusterpoint wikipedia , lookup
Versant Object Database wikipedia , lookup
Modellering og diagrammer Jesper Tørresø DAB1 E08 17. september 2008 Lektion i dag • Primære fokus på ERD diagrammer for at koble udviklingsarbejdet til en Relationsdatabase • De samme begreber og teknikker kan også bruges i forbindelse med UML diagrammer, som vi ”kun” ser på summarisk • Modelleringsprincipperne er i fokus!! Udviklingsforløb Model • A data model is a precise description of information content • Types of data models – Conceptual: in terms that users will understand – Logical: in terms that a relational database system will understand – Physical: in terms of the underlying computer hardware and operating system • Database schemas – Schema is another word for model that implies that it adheres to a particular strategy for defining models Schema (Short hand form) • A Schema is a data model that is intended to be used with a database system – External schemas are defined for the users of a database – Logical schema defines the representation as a collection of tables that are stored in a database server – Internal schema defines the representation used by the database server to store the tables in memory or files External schema 1 Datab ase tab les External schema 2 External schema 3 External level Logical to external mappings Logical schema Logical level Internal to logical mapping disk Internal schema Internal level Modeldiagrammer • Model kan vises med et eller flere diagrammer: – Entity Relationsship Diagram, ”Chen notation”. Udviklet til Databaser og ”imødekommer” kravene fra en RDB – ”Crows-Foot” – IDEF1X – UML (Scott Amber Agiledata.org) ER Diagram komponeter Generalisering /Specialisering Aggregering From time to time used.. SW-product A Program User’s Guide Ternary relationship Ternary relationship Ternary relationship • Assertion 1: One engineer, working under one mananger, could be working on many projects • Assertion 2: One project, under direction of one manager, could have many engineers • Assertion 3: One engineer, working on one project, must have only one manager. FD (EmpId, ProjectName -> ManagerID) N Manager 1 Assigned to N Engineer Project Ternary relationship Note on Ternary In general, for a n-ary relationship, each entity considered to be ”one” has its key appering on the right side of exactly one functional dependency (FD). No entity considerede ”many” ever has its key appear on the right side of an FD. N Manager 1 Assigen to N Project Engineer FD (EmpId, ProjectName -> ManagerID)