DB02 - Task Assignment
DB02 - Task Assignment
Referential integrity is crucial in database design to maintain consistency among tables by ensuring that relationships between tables remain consistent. For instance, the instructions in Source 1 call for appropriate constraints to be applied during table creation, such as foreign keys, to ensure that references between tables like PRODUCT and FAMILY or STOCK and TIENDA are valid. This prevents orphaned records and ensures that all data remains synchronized across the database .
To ensure that the column 'Beneficio' in the STOCK table only accepts the values 1, 2, 3, 4, or 5, the appropriate SQL constraint would be a CHECK constraint. This constraint can be defined in the CreateStore.sql script as follows: 'ALTER TABLE STOCK ADD CONSTRAINT chk_beneficio CHECK (Beneficio IN (1, 2, 3, 4, 5));'. This ensures that any value inserted into the 'Beneficio' column is validated against this condition and restricts it within the specified set .
Renaming a table impacts all existing SQL queries and database design components that reference the table name. For instance, changing STOCK to PRODXTIENDAS requires updating all SQL queries, views, stored procedures, and possibly application code that interact with the STOCK table. Such an action demands careful review and testing to ensure no functional disruptions occur due to the change .
To enforce the restriction that only one store can exist per area identified by the zip code, a UNIQUE constraint must be set on the zip code column in the TIENDA table. This can be achieved by modifying the table as follows: 'ALTER TABLE TIENDA ADD CONSTRAINT unico_zip UNIQUE (zipcode);'. This constraint will ensure that each value in the zip code column is distinct, thus adhering to the single store per area requirement .
The rationale for removing a column such as the Description column from the PRODUCT table might include reducing redundancy, improving performance, or reflecting changes in business requirements. Unnecessary or redundant data can lead to increased storage needs and complexity, while streamlined tables can enhance query performance and maintenance efficiency. Removing columns must also align with current or future application needs .
Modifying a column size involves using the ALTER TABLE command to adjust the column definition. For the Denoproducto column, the process is carried out with the statement: 'ALTER TABLE PRODUCTO MODIFY (Denoproducto VARCHAR2(50));'. This change allows the column to store longer strings, accommodating broader input requirements without affecting the rest of the table structure .
Applying constraints to columns, like the IVA column in the FAMILY table, is significant for ensuring data integrity and consistency. Specifying a constraint such as 'CHECK (IVA IN (21, 10, 4));' ensures that IVA values conform to acceptable VAT percentages. Such constraints prevent entry errors, ensure compliance with business rules, and enhance data reliability within the database .
To delete a table and its contents in SQL, you use the DROP TABLE command. For the FAMILY table, this would be 'DROP TABLE FAMILIA;'. This command removes the table definition and all associated data, indexes, constraints, and triggers from the database .
To implement a default value constraint in SQL for a column, you can use the DEFAULT keyword in the column definition. For the 'FechaUltimaEntrada' column in the STOCK table, the following SQL statement can be used: 'ALTER TABLE STOCK ADD FechaUltimaEntrada DATE DEFAULT CURRENT_DATE;'. This sets the default value of 'FechaUltimaEntrada' to the current date whenever a new record is inserted without a specified value for this column .
User privileges management in SQL is handled through the GRANT and REVOKE commands. Initially, the user C##INVITADO was granted all privileges on the PRODUCT table using 'GRANT ALL PRIVILEGES ON PRODUCT TO C##INVITADO;'. Subsequently, privileges to modify the structure and delete the content from the PRODUCT table were revoked using 'REVOKE ALTER, DELETE ON PRODUCT FROM C##INVITADO;'. This sequence demonstrates granular control over database access and operations for specific users .