1 / 25

Identifying Entities

Identifying Entities. Houston we have a problem!. Database design often left very late in the process Not less important than other aspects Typically where it always gets landed in the process! It makes sense to work through each layer in turn

eweldon
Download Presentation

Identifying Entities

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Identifying Entities

  2. Houston we have a problem! • Database design often left very late in the process • Not less important than other aspects • Typically where it always gets landed in the process! • It makes sense to work through each layer in turn • There is a lot to think about here that is both complex and subtle • Some of this will serve as revision • Explore the difference between classes and entities

  3. Document Standards • Problems compounded by differing documentation standards • Chen notation (Peter Chen 1976) • Crows Foot Notation • UML • Entity Relationship Diagrams an afterthought in UML? • (Relational v Object Oriented Databases)

  4. House Site M 1 On The Chen Notation • A house must be on a site • A site may or may not have many houses • The dots indicate the membership class of related entities

  5. House Site The Crows Foot Notation • No indication of membership class

  6. House Site 1 0..* UML Notation • Again no indication of membership class • Pretty much identical to class diagram

  7. Which is Best? • Familiarity and personal preference • What standard you are told to use • Which standard the software we are using i.e. Enterprise Architect “encourages” us to use UML but there are plug-ins for other types • For the examples in this module we will be using the Crows Foot notation • Supported by Enterprise Architect allowing auto generated code • You get to decide what you use – be consistent

  8. What is the Difference between a Class and an Entity? • It really doesn’t help much when we have two documentation standards that look so similar • The rectangular boxes are inevitably going to look pretty similar until the subtleties are fully appreciated

  9. So what are the differences? • Classes do not persist • Classes are ultimately implemented as objects • When the function or program ends, the object ceases to exist • Entities are ultimately implemented as tables • Tables do not vanish once the program/function has completed

  10. Classes have Functionality Entities do not clsAddressBook MyAddressBook = new clsAddressBook(); MyAddressBook.FilterByPostCode(“LE1”);

  11. “But really – aren’t they basically the same thing?” • Compare the following… • Entity framework automates much of this

  12. Classes may have no link to any entity

  13. Customer Name Delivery Address Post Code Widget Order Order line 1 Product A Unit Cost Quant Tot Order line 1 Product B Unit Cost Quant Tot • OrderTotal Classes may manage multiple entities…

  14. More Complex Relationship • The data for the class would be derived from multiple tables • For example • Customer details would come from tblCustomer • Product details would come from tblProduct • There may be a stock check facility making use of tblStock • Some elements of the invoice would never ever be stored in the system • For example • Order line totals and the invoice total would be calculated on the fly • When the invoice is stored in the system the data contained in a single object would be distributed across multiple tables.

  15. Objects may be generated on-the fly • LINQ (Language-Integrated Query) • Query Language for Objects • Similar to SQL var queryLondonCustomers = from cust in customers where cust.City == "London"select cust;

  16. The Difference… • Entities are about storing stuff • Classes are about controlling stuff

  17. Normalisation/De-Normalisation Database normalization is the process of organizing the fields and tables of a relational database to minimize redundancy. Normalization usually involves dividing large tables into smaller (and less redundant) tables and defining relationships between them. The objective is to isolate data so that additions, deletions, and modifications of a field can be made in just one table and then propagated through the rest of the database using the defined relationships. (Wikipedea)

  18. Things to Consider • No row order significance We are insisting that the rows must be sorted as above otherwise we won’t know what shelf a product is on

  19. No Column Order Significance We are assuming that the columns must always be in this order otherwise we won’t know the person’s name.

  20. Each attribute value must have only a single value

  21. No Duplication

  22. Order Line Order Order Product Product Always Decompose Many to Many Relationships

  23. A B One to One Relationships • Do not exist (probably).

  24. De-Normalisation • Some times we deliberately step back from a normalised database to meet other requirements • E.g. System response time

  25. Other Places to Inform our Entity Design • Smoke and mirrors prototype • Class diagram • Sequence diagram

More Related