Timpul joaca un rol in multe modele de afaceri.
De exemplu: O carte poate fi verificata in afara bibliotecii de cateva ori, de persone diferite, sau de aceeasi persoana. Modelul poate necesita o urmarire a istoriei imprumutarii unei carti. Ganditi-va la o companie de distribuire a florilor sau la un department orasenesc al politiei.
Cum poate timpul juca un rol in informatiile de care ei au nevoie?
Data istorica este adesea folosita in afaceri pentru a gasi modele care pot sa arate calea spre metode mai eficiente de a face afaceri. Modelarea timpului intr-o afacere permite ca o astfel de data sa fie capturata.
Rapoartele ofera informatii care pot fi conduse dintr-o data. Un raport bine-facut poate oferi o informatie valoroasa pe care afacerea o poate folosi pentru imbogatirea operatiilor ei.
Entitatea DAY vs. Atributul Data
Consideram entitatea PURCHASE.
Veti include un atribut “data” daca doriti sa stiti cand elemental a fost urmarit. Daca vrem sa identificam modele – cum ar fi atunci cand oamenii cumpara haine vs. costume de baie vs. adidasi? – am dori sa stim temperature din acea perioada de timp.
Ce este gresit cu entitatea revizuita de mai jos?
Reamintiti-va 3NF: un atribut non-UID nu poate avea atribute proprii. Sunt atributele unei date din cauza temperaturii ridicate sau scazute, trebuie sa separam entitatea DAY.
Va puteti gadi la un raport util pe care afacerea il poate produce din aceasta data?
Restrictii legate de timp
Fii constient de restrictiile care pot rezulta din nevoia de a urmarii date si timpuri. Exemplu: Luati in considerare o scoala echitabila care detine mai multe trasaturi. Managerul inscrie voluntari care sa lucreze in ture diferite pentru trasaturi diferite. O trasatura este personalizata de un singur voluntar o data. Unii voluntari pot lucra mai multe ore; altii pot lucra mai putine ore in functie de timpul lor liber. Programa trebuie sa fie determinata anterior, astfel incat managerii sa stie care timpi nu sunt ocupati de niciun voluntar.
Iata o selectie de restrictii legate de timp care trebuie sa fie luate in considerare pentru acest model : cea mai evidenta: schimbul “timpul sfarsit” trebuie sa fie mai tarziu decat schimbul “timpul inceput”. Timpii schimburilor nu trebuie sa se suprapuna. “Timpul inceput” al unui schimb pentu un voluntar nu trebuie sa fie intre niciun “timp inceput” si “timp sfarsit” ale altui voluntar din aceeasi caracteristica. La fel este si pentru “timpul sfarsit”.
“Timpul start” al unui schimb poate fi acualizat la un timp mai tarziu, doar daca schimbul nu a inceput deja. “Timpul start” al unui schimb poate fi acualizat la un timp mai devreme, doar daca schimbul nu a inceput deja. Probabil nu vei aproba ca un schimb sa fie mutat la un alt voluntar sau la alta caracteristica, doar daca schimbul nu a inceput deja. Acesta este un exemplu de conditie nontransferabila.
Conditii nontransferabile
Nontransferabilitatea: un SHIFT ASSIGNMENT nu poate fi schimbat la un alt BOOTH (sau alt VOLUNTEER). Relatiile nontransferabile sunt reprezentate printr-un diamante in ERD .
Nontransferabilitatea conditionala: un SHIFT ASSIGNMENT poate fi schimbata uneori-in acest caz, daca schimbul nu a fost inceput deja. Relatiile nu pot fi reprezentate in diagrama, dar si asa trebuie documentate.
|
