Forem: Arinze

Python Word Split Algorithm, Coderbyte

Arinze — Fri, 17 Jun 2022 10:17:43 +0000

Problem Definition:

Have the function WordSplit(strArr) read the array of strings stored in strArr, which will contain 2 elements: the first element will be a sequence of characters, and the second element will be a long string of comma-seperated words, in alphabetical order, that represents a dictionary of some arbitrary length. For example: strArr can be:
["hellocat", "apple, bat, cat, goodbye, hello, yellow, why"].
Your goal is to determine if the first element in the input can be split into two words, where both words in the dictionary that is provided in the second input.
In this example, the firs element can be split into two words:
hello and cat because both of those words are in the dictionary.

Your program should return the two words that exist in the dictionary separated by a comma. So for the example above, your program should return hello, cat. There will only be one correct way to split the first element of characters into two words. If there is no way to split string into two words that exist in the dictionary, return the string not possible. The first element itself will never exist in the dictionary as a real word.

# define the function to manipulate string

def WordSplit(strArr):
  for i, j in enumerate(strArr[1].split(',')):
    '''subtract a string from the main string'''

    new = strArr[0].replace(j.strip(),'')  

    '''then search through the other strings and compare with the remainder after subtraction'''

    for x in strArr[1].split(','):
      if new == x.strip():
        if strArr[0] == j.strip() + new:
          return f'{j.strip()},{new}'

  return 'not possible'

strArr = ['baseball', 'a, all, b, ball,base,  bas,  cat, code, d, e, quit, z'] #test case

response = WordSplit(strArr)    
'''intersperse this code with the ouput of the function'''
code = 'fg23klq6r9'

print(response )
intersperse = ''.join(i+j for i, j in zip(response, code))
print(intersperse )

Relational Database Design to store University timetables and record of students’ attendance.

Arinze — Sun, 20 Dec 2020 22:39:14 +0000

WORK OUTLINE:

PROBLEM AREA
SCOPE OF WORK
RELATIONSHIPS
ENTITY RELATIONSHIP DIAGRAM (ASSUMPTIONS/LIMITATIONS)
RELATIONAL TABLES
SCHEMA NORMALIZATION
FINAL SCHEMA DESIGN

1. PROBLEM AREA

Design a relational database for a University to store records of timetables and keep proper track of students’ attendance.

2. SCOPE OF WORK

I have properly studied the case/problem, considering all the information provided and put in this report assumptions and limitations to the data model adopted in a bid to cater for real life scenarios even within the context of this work.

3. RELATIONSHIPS

In the ER Diagram below, there are relationships between entities which enforces the constraints on both sides of the relationship (side of Entity A, side of Entity B).

The keys are as follows:

Key cardinality	Explanation
1:1	This is a one to one relationship between entities A and B, where one element of A can only be linked to one element of B and vice versa
1:1..*	This is a one to many relationship between entities A and B, where one element of A can be linked to many elements of B but a member of B is only linked to one element of A.
1..:1..	Many to Many relationship, many elements of A can be linked to that of B and vice versa.

4.1 ENTITY RELATIONSHIP DIAGRAM

4.2 ER Explanations and adequate assumptions:

There is a one to many relationship between the School and Course Entities. This is on the premise that a school runs multiple courses. School_ID is the primary key in the school entity and a foreign key in the course entity while Course_ID is the primary key in the course table.
There is a one to many relationship between the Course and Module Entities. This is from the case which states that a course contains multiple Modules. Course_ID and Module_Code are the primary keys of the course and module entities respectively and
Course_ID is a foreign key in Module table for the relationship.
The relationship between the Module and Session entities is a One to Many relationship. This is on the assumption that a module i.e CMM524 will constitute many sessions. Module_Code and Session_ID are the respective primary keys with Module_Code being the foreign key in Session table representing the relationship.
The Timetable required as in the case can be derived from the relationship between the primary (composite) keys in the School, Course, Semester and Module and Session entities. This will be discussed in more details later.
Course and Semester entities are on a one to many relationship. This has that one course can include one or many semesters. Course_ID and Semester_ID are the primary keys in their respective tables. Course_ID is a foreign key in semester to represent the one to many relationship.
A one to many relationship also exists between the module and semester entities; thus stating that one module can be taught in many semesters. Module_Code and Semester_ID are the respective primary keys. Module_Code is another foreign key in the semester table based on the relationship. A Semester is assumed to be in the academic calender year i.e 1st Semester (01) runs from September to December, 2nd Semester (02) runs from January to May while 3rd Semester (03) runs from June to August.
There’s a one to many relationship between Course and Student entities signifying that a course can have many students enrolled into it and many students can enroll for a course. There are Student_ID and Course_ID as primary keys for both entities.
Course_ID is the foreign key in student entity representing that relationship.
A student will have different student IDs for undergraduate degree and post graduate programs. The Student ID for a particular student for undergraduate i.e. BSc Yoruba Engineering will be different for MSc and then PHD Yoruba Engineering.
An assumption was made in the Session Entity which has that the Room_No attribute values can point to which type of session is in the particular session’s room. This means that a particular Lecture Room number LTR_100 will be for lectures only as the prefix LTR points to a lecture room. Similarly, Tutorial Room (TTR_200) will be used for tutorial only as the TTR prefix is for tutorial rooms and Lab Room (LBR_300) for laboratory purposes only as it the prefix LBR is for Lab rooms. The Room attribute value has a dual functionality in the table in identifying the Room number and the session type.
There is a Many to Many relationship between Student and Session represented by the attends relationship. This has that many students can be a part of many sessions. Student_ID and Session_ID are the primary keys. The many to many relationship
extends to a new table attendance which would contain the primary keys from the original tables as foreign keys. There is an attribute, attendance_record which would determine if the student attended the session or not. The attribute/column will have a Boolean data type (True or False) which would return True if the student attended the session or false if the student was absent.

4C. ER LIMITATIONS

There is a possibility that the Course and Session entities have a many to many relationships. This will lead to a new table to be created in the physical schema design having the primary keys of both tables in it.
In the event that a lecture is taken in a Lab or Tutorial Room, this will render my assumption is point (9) above invalid. As an adjustment, the record that can be inserted into the table or record updated stating the Room_No = “Room number of room used” which would point to whether it was a Lecture, Lab or Tutorial

5. RELATIONAL TABLES

After mapping the Entity Relationship Diagram above to relational tables, I have the following sets of tables and their mappings showing their relationship:

The School and Course tables showing the one to many relationship via the foreign key (School_ID).

The Course and Module tables showing the one to many relationship via the foreign key (Course_ID)

The Module and Session tables showing their one to many relationship via the foreign key (Module_Code).

The Course and Semester tables showing their one to many relationship via the foreign key (Course_ID)

The Module and Semester tables showing their one to many relationship via the foreign key (Module_Code)

The Course and Student tables showing their one to many relationship via the foreign key (Course_ID).

The Student and Session tables showing their many to many relationship via a new table ATTENDANCE, having the primary keys of both tables as composite keys.

6. SCHEMA NORMALIZATION

1. SCHOOL

The School Table has a primary key School_ID which has one other attribute/column School_Name which is the name or a description of the different schools. A sample design of the Table is shown below:

For normalization, I have that:

The School table is in 1NF as all attributes are atomic.
For 2NF, there’s a full functional dependency on School_ID from School_Name. The non-prime attribute School_Name is fully functionally dependent on the primary key School_ID as represented below.

School_ID -> School_Name {full functional dependency}
The table is in 3NF as there is no transitive dependencies on the primary key.

2. COURSE

Based on my design, the Course table has a primary key, Course_ID uniquely identifying every module and another attribute Course_Name which gives a name or a brief description of each course.

For normalization, I have that:

The Course table is in 1NF as all attributes are atomic.
For 2NF, there’s a full functional dependency on Course_ID from Course_Name. The non-prime attribute Course_Name is fully functionally dependent on the primary key Course_ID as represented below.

Course_ID -> Course_Name {full functional dependency}

The table is in 3NF as there is no transitive dependencies on the primary key.

3. MODULE

The Module entity like the two previously discussed, has a primary ID, Module_Code and one other attribute Module_Name showing the Names or descriptions of different modules.

To show normalization on the Module Table:

The table is in 1NF as all attributes are atomic as in the design above.
For 2NF, there’s a full functional dependency on Module_Code from Module_Name. The non-prime attribute Module_Name is fully functionally dependent on the primary key Module_Code as represented below.

Module_Code > Module_Name {full functional dependency}

The table is in 3NF as there is no transitive dependencies on the primary key

4. SESSION

As I discussed earlier, my session table is going to be uniquely a user defined object table such that some columns(attributes) like the primary key (Session_ID) and Room_No which would naturally determine that type of session type it is (Lecture, Lab, Tutorial).

The Session table has primary key Session_ID which uniquely identifies each record on the table considering the Room attribute can point to which session is holding in it. The session date and time specifies the date and time a session took or is to take place.

To show normalization on the Session Table:

The table is in 1NF as all attributes are atomic.
For 2NF, there’s a full functional dependency of all the non-prime attributes on the primary key. The non-prime attribute Room_No, Session_Date and Session_Time are fully functionally dependent on the primary key Session_ID as represented below.

Session_ID > Room_No {full functional dependency}

Session_ID > Session_Date {full functional dependency}

Session_ID > Session_Time {full functional dependency}

The table is in 3NF as there is no transitive dependencies on the primary key

5. SEMESTER

The semester table has a semester_ID that will uniquely identify each record on the table. The semester_year represents the year the semester is in and the semester_code represents the semester in that semester/school calendar year. An example can be semester
ID SEMPLE03, which according to the table is year 2020 3rd Semester. To maintain the integrity of the schema, there’s a constraint that for a particular semester_year attribute (i.e.
2019) will only have values (01,02,03). This is to maintain the integrity and avoid redundancies or/and data inconsistency. The variances for dates obtainable for each semester as in (6) of the assumption module of this document.

For Normalization:

The table is in 1NF as all attributes are atomic as in the design above.
For 2NF, the 2 attributes are fully functionally dependent on the primary key and as such meets the 2NF requirement.

Semester_ID > Semester_Year {full functional dependency}

Semester_ID > Semester_Code {full functional dependency}

The table is in 3NF as there is no transitive dependencies on the primary key.

6. STUDENT

The Student table has a primary key Student_ID which is unique and a student_name attribute given the name of student. A schema sample is seen below:

To show normalization on the Student Table:

The table is in 1NF as all attributes are atomic as in the design above.
For 2NF, there’s a full functional dependency on Student_ID from Student_Name. The non-prime attribute Student_Name is fully functionally dependent on the primary key Student_ID as represented below.

Student_ID > Module_Name {full functional dependency}

The table is in 3NF as there is no transitive dependencies on the primary key

7. ATTENDANCE

The Attendance table is a result of a many to many relationship between the Student and Session tables. The table has a composite key comprising the Primary keys Student_ID and Session_ID has was from both related tables. There is another attribute, Attendance_Record which I assumed will form the basis of attendance. The column will have a Boolean data type which would contain the value “TRUE” if the Student attended and “FALSE” if the student didn’t attend.

To show normalization on the Attendance sample Table:

The table is in 1NF as all attributes are atomic as sample.
Attendance_Record has a full functional dependency on the composite keys hence the 2NF confirmation and as seen below:

Student_ID, Session_ID > Attendance_Record {full functional dependency}

The table is in 3NF as there is no transitive dependencies on the composite keys

The Attendance table will give the attendance record of a student for a particular session. A table that combines primary keys from the School, Course, Semester, Module and Session will supply the universities timetable.

Final Schema descriptions (Table Names, keys, columns and meanings) have been done in the Relational Tables & Schema Normalization portions of this document.

Designing a Relational Database for Little Panda, a takeaway restaurant

Arinze — Sun, 20 Dec 2020 18:14:36 +0000

Designing a Relational Database for Little Panda

Little Panda is a takeaway who wants to open up its business to accept online orders. To do this, it needs a database to store its food menu, customer data and orders.

Key Requirements to design the relational database that runs on MySQL

Customers must register before they can make orders. They must
provide enough details for home delivery.
Menu item prices may change. Customers are charged prices at the
time of order.
Little Panda needs to know the status of an order so that they can follow up. e.g. either it is “waiting to be cooked”, “cooked and to be delivered”, or delivered, etc. You can assume all orders are paid before they enter the
system.
Order details must be stored for accounting purpose, even after they are
completed.

Scope of Work and Defining Relationships

Having considered the Little Panda case study and the requirements, I have come up with the following steps:
1. Design of the Entity Relation Diagram
2. Explaining the Design and stating assumptions
3. Stating Limitations where necessary
4. Defining Relationships Between Tables
5. Schema Normalization and Final Design

Relationships between entities

From the ER derived based on the requirements, given entities A and B, the identified relationships between them are represented with the keys below.

Key cardinality	Explanation
1:1	This is a one to one relationship between entities A and B, where one element of A can only be linked to one element of B and vice versa
1:1..*	This is a one to many relationship between entities A and B, where one element of A can be linked to many elements of B but a member of B is only linked to one element of A.
1..:1..	Many to Many relationship, many elements of A can be linked to that of B and vice versa.

I. The Entity Relationship Diagram

II. Explaining the Design and Stating Assumptions

From the ER diagram, there is a one to many relationship between the customer and the payment entities. This is on the assumption that a customer can make many payments, but one payment cannot be linked to many customers. Customer_ID the primary key in the customer entity will be a secondary key in the payment entity, which has Payment_ID as primary key.
Between the customer and order entities, there is a many to many relationship. This is based on the premise that a customer can place many orders and same type of order can belong to many customers. However, the address can be extended to a bridge table as a customer can place an order using more than one address. The Customer_ID and Order_ID are primary keys in their respective entities, but will be used as a foreign keys in the address table.
The relationship between customer and order also on the premise that a customer can order for someone living in a different address different from the address used in registering.
There is a many to many relationship between the order and menu entities. This was derived from an order having many items from a menu and one item in a menu linked to more than one order. The Menu_ID and Order_ID are the primary keys in their respective entities. On the other hand, the order details can be used to bridge the two tables taking their respective primary keys as a foreign key.
The order table has a status attribute which can be used to always know the point in the process where the order is.
The order and payment entities are presumed to have a one to one relationship, as any payment made can only be linked to an order.
An order from a customer can contain various items from the menu.
The address of a customer contains the necessary information to deliver an order to the customer.

III. Limitations Identified

The address of the customer is considered atomic and can be used to deliver to the required customer.

IV. Defining Relationships between tables

With the ER diagram defined in figure 1 above, this section is to show the sets of tables derived and their relationships.

The one to many relationship between customer and payment is shown below and respective primary and foreign keys assigned.

The many to many relationship between the customer and order will be taken care of by adding an address table, because of the assumptions made.

The one to one relationship between the payment and order entities are shown with the tables below. They have their respective primary keys, however the Order_ID is a foreign key in the payment table.

The order and menu entities which are represented with a joint table, to account for the many to many relationship. The order details table will be used as joint table for this table and will contain primary keys of order and menu tables, as foreign keys.

V. Schema Normalization and Final Design

1. CUSTOMER

From the customer table below, the Customer_ID is the primary key, where as the customer name, customer email and customer phone are other attributes.

Customer Table Normalization:

The Customer table is in 1NF as all attributes are atomic.
For 2NF, there is a full functional dependency of Cusomer_Name,
Customer_Email and Customer_Phone on the Customer_ID primary key. They are non-prime attributes which are fully functionally dependent on the primary key Customer_ID as represented below.

Customer_ID-> Customer_Name {full functional dependency}

Customer_ID-> Customer_Email {full functional dependency}

Customer_ID-> Customer_Phone {full functional dependency}
The table is in 3NF as there is no transitive dependencies on the primary key.

2. PAYMENT

The payment table below has Payment_ID as the primary key. The
Total_Amount, Payment_Datetime, Payment_Method are other dependent
attributes. The Payment_ID uniquely identifies all the payment entries made

Payment Table Normalization:

The Payment table is in 1NF as all attributes are atomic.
For 2NF, there is a full functional dependency of Total_Amount,
Payment_Datetime and Payment_Method on the Payment_ID primary key.
They are non-prime attributes which are fully functionally dependent on the primary key Payment_ID as represented below.

Payment_ID -> Total_Amount {full functional dependency}

Payment_ID -> Payment_Datetime {full functional dependency}

Payment_ID -> Payment_Method {full functional dependency}
The table is in 3NF as there is no transitive dependencies on the primary key.

3. ORDER

The order table below has Order_ID as the primary key. The Order_Datetime and Order_Status are other dependent attributes. The Order_ID uniquely identifies all the order entries made. On the other hand, an order details table will be subsequently introduced, to identify the link to content of each order
made.

Order Table Normalization:

The Order table is in 1NF as all attributes are atomic.
For 2NF, there is a full functional dependency of Order_Datetime and Order_Status on the Order_ID primary key. They are non-prime attributes which are fully functionally dependent on the primary key Order_ID as represented below.

Order_ID Order_Datetime {full functional dependency}

Order_ID Order_Status {full functional dependency}
The table is in 3NF as there is no transitive dependencies on the primary key.

4. ADDRESS

There is an assumption that a customer can order to multiple address at different point in time. The address table will be used to identify a customer’s order, with their respective address. The Customer_ID and Order_ID are the composite keys from the customer and order tables, where they serve as primary keys.

Address Table Normalization:

The Address table is in 1NF as all attributes are atomic.
For 2NF, there is a full functional dependency of Address_Line on the composite keys, as shown below.

Customer_ID, Order_ID -> Address_Line {full functional dependency}

The table is in 3NF as there is no transitive dependencies on the primary key

5. ORDER DETAIL

The order detail table is a joint table between the order and menu tables. The Order_Quantity and Total_Price are dependent on the Order_ID and Menu_ID which are composite keys.

Address Table Normalization:

The Order table is in 1NF as all attributes are atomic.
For 2NF, there is a full functional dependency of Order_Quantity and Total_Price on the composite keys, as shown below.

Order_ID, Menu_ID -> Order_Quantity {full functional dependency}
Order_ID, Menu_ID -> Total_Price {full functional dependency}
The table is in 3NF as there is no transitive dependencies on the primary key.

6. MENU

The menu table below has Menu_ID as the primary key. The Menu_Name, Menu_Price and Menu_Description are other dependent attributes. The Menu_ID uniquely identifies each menu item.

Payment Table Normalization:

The Menu table is in 1NF as all attributes are atomic.
For 2NF, there is a full functional dependency of Menu_Name, Menu_Price and Menu_Description on the Menu_ID primary key. They are non-prime attributes which are fully functionally dependent on the primary key Menu_ID as represented below. Menu_ID -> Menu_Name {full functional dependency} Menu_ID -> Menu_Price {full functional dependency} Menu_ID -> Menu_Description {full functional dependency}
The table is in 3NF as there is no transitive dependencies on the primary key.

The final design schema in figure 2 below, shows the identified and normalized tables with their various primary keys and attributes.

FINAL SCHEMA DESIGN

Feel free to leave a comment on any part of the document that interests you.