database and relative
  • Introduction
  • database
  • SQL
  • different kinds of Database
  • JDBC
  • oracle
  • MySQL
  • hibernate1
  • JavaPersistence:HibernateandJPAFundamentals0
  • keys
  • NoSQL DB
Powered by GitBook
On this page
  • 1. SQL join
  • 2. normalization denormalization
  • 3 What do Clustered and Non clustered index actually mean?
  • 4. Relationship Types
  • 4.1 One-One Relationship
  • 5. Isolation Level

Was this helpful?

SQL

PreviousdatabaseNextdifferent kinds of Database

Last updated 5 years ago

Was this helpful?

1. SQL join

outer join: left join+right join;

left join

right join

inner join

left excluding join

right excluding join

full outer join

outer excluding join

eg:

SELECT Orders.OrderID, Customers.CustomerName, Orders.OrderDate
FROM Orders
INNER JOIN Customers ON Orders.CustomerID=Customers.CustomerID;

2. normalization denormalization

Normalization is the process of efficiently organizing data in a database. There are two goals of the normalization process: eliminating redundant data (for example, storing the same data in more than one table) and ensuring data dependencies make sense (only storing related data in a table). Both of these are worthy goals as they reduce the amount of space a database consumes and ensure that data is logically stored. There are several benefits for using Normalization in Database.

Benefits :

  1. Eliminate data redundancy

  2. Improve performance

  3. Query optimization

  4. Faster update due to less number of columns in one table

  5. Index improvement

Normalization and denormalization are the methods used in databases. The terms are differentiable where Normalization is a technique of minimizing the insertion, deletion and update anomalies through eliminating the redundant data. On the other hand, Denormalization is the inverse process of normalization where the redundancy is added to the data to improve the performance of the specific application and data integrity.

3 What do Clustered and Non clustered index actually mean?

An index is an on-disk structure associated with a table or view that speeds retrieval of rows from the table or view. An index contains keys built from one or more columns in the table or view. These keys are stored in a structure (B-tree) that enables SQL Server to find the row or rows associated with the key values quickly and efficiently.

A table or view can contain the following types of indexes:

  • Clustered

    • Clustered indexes sort and store the data rows in the table or view based on their key values. These are the columns included in the index definition. There can be only one clustered index per table, because the data rows themselves can be sorted in only one order.

    • The only time the data rows in a table are stored in sorted order is when the table contains a clustered index. When a table has a clustered index, the table is called a clustered table. If a table has no clustered index, its data rows are stored in an unordered structure called a heap.

  • Nonclustered

    • Nonclustered indexes have a structure separate from the data rows. A nonclustered index contains the nonclustered index key values and each key value entry has a pointer to the data row that contains the key value.

    • The pointer from an index row in a nonclustered index to a data row is called a row locator. The structure of the row locator depends on whether the data pages are stored in a heap or a clustered table. For a heap, a row locator is a pointer to the row. For a clustered table, the row locator is the clustered index key.

    • You can add nonkey columns to the leaf level of the nonclustered index to by-pass existing index key limits, and execute fully covered, indexed, queries.

    Both clustered and nonclustered indexes can be unique. This means no two rows can have the same value for the index key. Otherwise, the index is not unique and multiple rows can share the same key value.

    Indexes are automatically maintained for a table or view whenever the table data is modified.

4. Relationship Types

4.1 One-One Relationship

One-to-One relationship is defined as the relationship between two tables where both the tables should be associated with each other based on only one matching row. This relationship can be created using Primary key-Unique foreign key constraints.

  • One-to-one: Both tables can have only one record on either side of the relationship. Each primary key value relates to only one (or no) record in the related table. They're like spouses—you may or may not be married, but if you are, both you and your spouse have only one spouse. Most one-to-one relationships are forced by business rules and don't flow naturally from the data. In the absence of such a rule, you can usually combine both tables into one table without breaking any normalization rules.

  • One-to-many: The primary key table contains only one record that relates to none, one, or many records in the related table. This relationship is similar to the one between you and a parent. You have only one mother, but your mother may have several children.

  • Many-to-many: Each record in both tables can relate to any number of records (or no records) in the other table. For instance, if you have several siblings, so do your siblings (have many siblings). Many-to-many relationships require a third table, known as an associate or linking table, because relational systems can't directly accommodate the relationship.

Problems with Many-to-Many Relationships

A many-to-many relationship has an inherent peculiarity that you must address before you can effectively use the data from the tables involved in the relationship. The issue is this: How do you easily associate records from the first table with records in the second table in order to establish the relationship? This is an important question because you'll encounter problems such as these if you do not establish the relationship properly:

  • It will be tedious and somewhat difficult to retrieve information from one of the tables.

  • One of the tables will contain a large amount of redundant data.

  • Duplicate data will exist within both tables.

  • It will be difficult for you to insert, update, and delete data.

5. Isolation Level

Read committed is the default isolation level for Oracle DB. And Oracle only support Serializable and Read committed.

MySQL support Read uncommitted, Read committed, Repeatable read and Seriallizable 4 levels. And Repeatable Read is the default level.

https://docs.microsoft.com/en-us/sql/relational-databases/indexes/clustered-and-nonclustered-indexes-described