| | 1 | = Relational Model - ER Diagram = |
| | 2 | |
| | 3 | == Laboratory and Organization == |
| | 4 | |
| | 5 | The system stores information about laboratories, departments, employees, roles, and work schedules. |
| | 6 | |
| | 7 | A laboratory (LAB) contains multiple departments (DEPARTMENT), while each department employs multiple employees (EMPLOYEE). Employee information includes personal data, EMBG, hiring date, and activity status. |
| | 8 | |
| | 9 | Since employees may have multiple roles, the many-to-many relationship between EMPLOYEE and EMPLOYEE_ROLE is resolved through EMPLOYEE_ROLE_ASSIGNMENT. Employee schedules are managed through EMPLOYEE_SCHEDULE. |
| | 10 | |
| | 11 | == Equipment == |
| | 12 | |
| | 13 | The system manages laboratory equipment through the LAB_EQUIPMENT entity. Each piece of equipment stores information such as name, model, serial number, and status. |
| | 14 | |
| | 15 | Employee qualifications for operating equipment are managed through EMPLOYEE_EQUIPMENT_SKILL, which resolves the many-to-many relationship between employees and equipment. |
| | 16 | |
| | 17 | == Patients and Requests == |
| | 18 | |
| | 19 | Patients are stored in the PATIENT entity, including personal information, EMBG, gender, contact details, and status. |
| | 20 | |
| | 21 | Each patient visit generates a LAB_REQUEST. Every request belongs to exactly one patient and one laboratory and contains information about the request date and status. |
| | 22 | |
| | 23 | == Samples == |
| | 24 | |
| | 25 | A laboratory request may contain multiple samples. Samples are stored in the SAMPLE entity and include barcode, collection date, status, sample type, and the employee responsible for collection. |
| | 26 | |
| | 27 | == Tests and Analysis Packages == |
| | 28 | |
| | 29 | The system supports individual laboratory tests and analysis packages. |
| | 30 | |
| | 31 | TEST_TYPE defines categories of tests, while TEST stores specific laboratory tests and their prices. |
| | 32 | |
| | 33 | ANALYSIS_PACKAGE represents groups of tests. The many-to-many relationship between packages and tests is implemented through TEST_IN_PACKAGE. |
| | 34 | |
| | 35 | == Orders == |
| | 36 | |
| | 37 | Patients can order either individual tests or analysis packages. |
| | 38 | |
| | 39 | * ORDERED_TEST – individual tests |
| | 40 | * ORDERED_PACKAGE – analysis packages |
| | 41 | |
| | 42 | Both entities are linked to LAB_REQUEST. |
| | 43 | |
| | 44 | == Results == |
| | 45 | |
| | 46 | Laboratory results are stored in TEST_RESULT, the central entity of the system. |
| | 47 | |
| | 48 | Each result is associated with: |
| | 49 | |
| | 50 | * a sample |
| | 51 | * a test |
| | 52 | * a result parameter |
| | 53 | * the employee who entered the result |
| | 54 | |
| | 55 | Result values are stored as VARCHAR because they may contain either numerical or textual values. |
| | 56 | |
| | 57 | The system enforces an XOR constraint, ensuring that each result originates either from ORDERED_TEST or from ORDERED_PACKAGE, but never from both simultaneously. |
| | 58 | |
| | 59 | == ER Diagram == |
| | 60 | |